To understand the context of the present invention it may be helpful to the reader to have a concrete, but very simple exemplary computer network, such as that shown in FIG. 1 and indicated generally by reference numeral 10, to which the reader can refer. The computer network 10 is shown as including two host computers that are referred to here as client host computer 12 and server host computer 14. Those skilled in the art will understand that the designation of a host computer as a client or as a server in this context depends upon which host computer sent a request to begin an exchange of messages between the host computers 12, 14. For the purposes of this discussion it is assumed that the client host computer 12 is running a client-side network application that needs to have some processing done by a server-side network application running on the server host computer 14. Generally, the client host computer 12 will include a central processing unit (“CPU”) 16 and memory 18. The CPU 16 runs the operating system 20 of the client host computer 12. In addition, the CPU 16 may run client-side network applications. The client host computer 12 interfaces with a communications network 22 through a communications interface 24. The communications network 22 may be a wired network or a wireless network or a partially wireless network and transports data between the host computers 12, 14. The communications interface 24 may be a modem or other means for interfacing between a computer and communications network 22.
Likewise, the server host computer 14 includes a CPU 26, memory 28 and an operating system 30. CPU 26 runs the operating system 30 of the server host computer 14 as well as server-side network applications. In addition, the server host computer 14 interfaces with the communications network 22 through a communications interface 32.
The elements of a simple computer network described above are known to those of ordinary skill in the art and will not be described further herein.
A client-side network application must rely on the computer network's transport system to communicate requests (sometimes referred to as “remote procedure calls” or “RPCs”) to a server-side network application. Typically, a software interface, usually referred to as a “socket”, is provided by an operating system 20, 30 for a network application to gain access to the transport system. On the client side, a socket is provided into which a client application can send requests to be transported to the server application. Similarly, on the server side, a socket is provided from which the server application can receive requests sent by the client application and into which the server application can send replies that need to be transported to the client application. Typically, if the computer network's transportation system is based upon the Internet Protocol (“IP”), network applications that need reliable transport use either the Transmission Control Protocol (“TCP”) or include their own procedures to provide reliable transport using the User Datagram Protocol (“UDP”). In the latter case, this means that each time a network application is written for or ported to a new network configuration, significant effort is generally required to provide optimal reliable transport.
For example, a client application may need to send requests to a server application through a transport system that includes a wireless link. The transport system may have a high degree of error correction built in and may include a dedicated channel for some requests that the client applications may wish to send to some server applications. In such a situation, the reliable transport mechanisms built into TCP are not optimal for requests transmitted to all server applications over the wireless link. Because lost requests are very likely to be due to data loss in the wireless link rather than collisions or buffer overflow due to congestion, for urgent requests (e.g., for signaling that a user has picked up a telephone handset in an voice over Internet application) that will pass through the wireless link it may be preferable to retransmit an apparently lost request with a relatively long (in computer terms), but constant, delay between retransmissions and with a small hard limit on the number of retransmissions before an error is reported. However, for requests that do not pass through the wireless link or are less urgent, but which must be delivered, it may be preferable to have an initially shorter delay between retransmissions, a retransmission delay that increases linearly, and a very large number of retransmissions before an error is reported. In other cases, a protocol that handles retransmission in the manner in which TCP handles retransmissions may be desirable. Moreover, conditions in the network may change with interference in the wireless link or loading of the wire-line portion of the network, even if the network is dedicated to the network application (i.e., is not a public network like the Internet) and the radio spectrum used for the wireless is dedicated to the network.
Implementing a network application that can reliably handle remote procedure calls has in the past been done by either living with the limitations of TCP or building reliable transport into the network application and using UDP. For example, application-layer protocols such as Media Gateway Control Protocol (“MGCP”) or Session Initiation Protocol (“SIP”) include specifications for reliable transport that can be implemented in network applications that use remote procedure calls for signaling so that the network application itself provides reliable data transport. However, doing this adds additional complexity to the network application and means that the network application must be modified or at least tuned whenever changes occur in the network such that remote procedure calls are transported over paths having new characteristics or whenever remote procedure calls are to be made that have different requirements for timing and reliability. It would be preferable if characteristics of reliable transport mechanism provided for a specific client application that must make remote procedure calls to a specific server application could be changed without modifying the application.
For example, in Voice-Over-Internet-Protocol (“VOIP”) applications, TCP and UDP are not optimal if a wireless link is involved. Such applications, if they are to provide carrier-grade voice communication, need to reliably establish a communication channel as soon as possible after a subscriber picks up a telephone handset. While such applications can tolerate some degree of media data loss in the digitized voice signal once a connection is established, signaling messages must be highly reliable if subscriber expectations raised by past experience with the Public Switched Telephone Network (“PSTN”) are to be satisfied. Network applications such as VOIP applications are typically implemented in accordance with application-layer protocols such as MGCP and SIP in which reliable transport aspects are intermingled with the application-specific aspects of the protocol. Such applications directly use the services of a transport layer that implements the UDP or possibly the TCP over an IP network.
There is a need for a method and system that provides an application layer that can be adapted or adapt itself to network applications and transport conditions without revising the underlying code in either the network application or the transport layer.